|
|
Excel interop?
Just been there (but I was mostly doing export - only had to read template & reporoduce - a lot easier than straight import.)
And then it was outlook - just finished (quick and dirty outlook util),
to cap it off possibly some word is next.
fun all around!
... really thinking about taking a few weeks holiday (even before #3).
Sin tack
the any key okay
|
|
|
|
|
Nope - not using Office Interop for it. That would have taken me far longer, and would have made it a fragile house of cards.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
not that fragile if done carefully, but fully agree it's definitely a challenge
(and the slowness is not just the dev, interop runs like a pig on rollerskates on ice, and then there's the challenge if the user is in that office app at the same time.)
Sin tack
the any key okay
|
|
|
|
|
I'm using ExcelDataReader (NuGet package) to load the data into a DataTable, and then doing all the mechanical stuff myself. Including the code that handles database queries and copious comments, it's less than 900 lines of code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: NuGet package
PTUI.
|
|
|
|
|
Without comments and blank lines (but still formatted), it's less than 500 lines. 
The larger the file, the longer it takes, but it's still much faster than using interop.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 17-Aug-17 13:59pm.
|
|
|
|
|
We've given up on trying to import Excel (via SSIS). The final nail in its coffin was that the Data Center folk said that we couldn't even put the Standalone ACE Engine on our servers -- "Oh no! That's MS Office! You can't put that on a server!"  . So now we do CSV instead.
How well does yours handle IPv4 addresses? I continually see SSIS importing them as floating-point values! 
|
|
|
|
|
Hmmm, it never occurred to me to try that. Lemme check real quick.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
string - BOO-YA! The caveat is that the column contain at least one value that cannot otherwise be interpreted as a double of course).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yes, and everyone but MS knows that you can't interpret an IPv4 address as a double.
|
|
|
|
|
My importer tries to determine the most appropriate data type for the column, the ultimate fallback type is string. If you have 100 rows of data, and the first 99 are doubles, but the last is an IP address (for instance), it will report the data type for that column as a string.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 17-Aug-17 13:32pm.
|
|
|
|
|
Sure, but then why would MS choke on a list containing all IPv4 addresses (nothing that looks like a double except to them). 
|
|
|
|
|
If you want, I can get a zip file together with some instructions for use, and email it to you to try out.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Have a look at NPOI
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
"Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed."
Either they aren't actually listed or they are buried so deep as to be invisible.
To the devs who wrote this pointlessness: If you can see there's a conflict why not list it then and there?
What about:
"Found conflicts between different versions of the same dependent assembly "Assembly.dll (1.2.3.4)" and "Assembly.dll (1.2.3.5)" that could not be resolved."
There - was that hard?
cheers
Chris Maunder
|
|
|
|
|
You are asking Microsoft to be user friendly?
I knew you were a glass half full person!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Been there. I was upgrading a project to newer versions of .NET Framework, ASP .NET MVC and the cascade of packages that needed to be updated when I ran into this. It is quite a manual task to figure out where the problems are and how to solve them.
The promise of freeing us from DLL hell, well, I am still waiting for that to be fulfilled.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
seriously, what's the point of upgrading target in an existing development (unless still very fresh)? If a mature project is happy in say 4.0 it really should be left there and NOT pushed to the new target.
1. avoid these issues
2. keeps installation simple - if got multiple proj's in a solution some not updated then have to install the multiple .net's on older machines
3. it's not as if ms fix anything - they just add more [mostly bloat - even then even older versions can achieve identical results perhaps albeit with a few more lines of code].
And really for the sake of "compatibility" often they can't or shouldn't ever fix some of the "mysterious"/"expected" issues/behaviours... many of their own apps would break if they did that.
Yes [nearly all] exception causing bugs can be fixed, but operating behaviours even if they seem wrong or non standard must never be changed
... imagine if they decided next version of .net would zero base VB arrays (and all the dumb-ass newbie devs quickly open VS and flick projects to the new target?)
In short:
- minimally a waste of time, but in fact
- a very bad practice.
Sin tack
the any key okay
|
|
|
|
|
It was not a mature project. The project was shelved years before and it was decided to dig it up and restart the effort. It is as simple as that.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
I respectfully disagree.
In my experience, it's often more cost effective to upgrade projects whenever they're in active development.
In part, because the newer toolchains are much easier to develop for. Easy build settings, better CI support, better reporting.
In part, because the old toolchains become obsolete.. and you need people with experience to fix those problems.
But most importantly: management expects everything to work everywhere whenever they feel like it.
Migrating to the most flexible target is always the safest bet.
|
|
|
|
|
I disagree as well. At some point most applications WILL need to be updated. It is far more effective to upgrade the framework or IDE one step at a time, rather than a huge jump when forced by other priorities.
Currently I support an oolldd vendor product. Last year it was still being compiled in Visual Studio 2005, but for various reasons needed to be upgraded. The vendor put in a lot of effort, tried to jump to VS2013, it failed. They had to regroup and compile first in VS2008 and then VS2010. They finally got it into VS2012, then quit as the product is being sunsetted.
At some point all software, including frameworks and compilers/IDEs, become obsolete. The business need for a product doesn't become obsolete, and business priorities and costs may keep a program around long after it should be rewritten. [this vendor product is the poster child!]
My team is writing a replacement. The current plan for the project I'm on is to stay on VS2015 (IDE we started with) until we publish. After that, when major changes need to be made, investigate the current MS IDE to determine if we should upgrade the framework and/or IDE. We probably won't do minor framework changes unless we need to, but major version will get looked at. By being proactive on keeping it current, this program will likely still be running fine 10 years from now.
At some point it will need to be rewritten ... but that's a business decision made above my pay grade. Until such time, we'll keep this puppy in optimal shape to meet the business need.
|
|
|
|
|
Lopatir wrote: it's not as if ms fix anything
At least according to the fix lists they do fix security problems.
|
|
|
|
|
Ya' know, I didn't have all of these problems I here of with VS2008.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
With VS2008 you just didn't hear about them 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
