|
OK.
So; Is there any workaround to execute action like copying the output folder to another location?
I have allready set the drop location but wanted to copy output folder automatically to another location in post build event.
|
|
|
|
|
aboutvb wrote: Is there any workaround to execute action like copying the output folder to another location?
Write a script of your own and run it manually?
Any other way, I cannot think of now.
|
|
|
|
|
Well, you could always convert it into a Web Application. Have a look here[^] for more details on the conversion process.
|
|
|
|
|
What version and edition of Visual Studio are you using?
There are build events in 2010. MyProject -> Compile tab -> Build Events button.
|
|
|
|
|
You don't get this in an ASP.NET web site, it has to be a web application.
|
|
|
|
|
OK, I must be missing something. Every ASP.NET project type I have (2010 Ultimate) has the Build Events button under "My Project".
What's the project template name that doesn't have it or do I have to do something different than creating a project from the tempate?
|
|
|
|
|
File > New > Web Site... > ASP.NET Web Site...
|
|
|
|
|
Ah! I never do that...
In that case, I'd probably just create a batch file to do the post-build stuff and drop a shortcut to it on the Taskbar. "Compile" then launch the batch manually.
|
|
|
|
|
I'm taking the jump from .NET 2.0 to 4.0 and I'm trying to understand the new methods for doing threading.
I am creating a WinForm app and need to have a thread which will be sent some data, do calculations, and send back data at some timed interval (say at 5x per second). The data will be plotted into an OpenGL window.
Would this be a job for a standard thread, a BackgroundWorker thread, or using the Task class?
I understand there may not be one answer for this, but I'm trying to understand when it is appropriate to use the newer threading classes available in 4.0. I am familiar with the older Thread class, but is it no longer the preferred method?
If there is a good explanation / differentiation on this please point me to it.
Thanks.
|
|
|
|
|
earl007 wrote: I am familiar with the older Thread class, but is it no longer the preferred method?
I'm using the BackgroundWorker if the thread-code only needs to synchronize to display some progress. I'm only using tasks inline, with code that needs to be executed async but merely consists of 5 lines code tops; used the ThreadPool for that in previous models.
--edit;
Still doesn't answer which would be preferred, only which I prefer when.
Bastard Programmer from Hell 
|
|
|
|
|
I have a DCOM client written in C# that works on some Win-7 computers but not others. It was developed on a XP machine,
and it works fine there. I call this app from another legacy app and it opens for a second, then shuts down with the
Windows message that it is "looking for a solution". It uses COM interfaces to connect to a Televantage phone system.
I have been over and over the dcomcnfg settings but have no luck. Nothing gets logged except a vague error in the Windows
Event Log > Application, and that is error 1001. I have exception logging built into my app, but it is shutting down
before anything gets logged. I can't tell if this is a security issue, or a .net framework issue. This app was developed in VS2008 for a .net 3.5 framework. The problem Win-7 computers have .net 4 installed. I really need to get
this running, and any help would be much appreciated.
Thanks
John
modified 26-Jun-12 0:06am.
|
|
|
|
|
If your app was developed against .NET 3.5 you MUST install .NET 3.5 on the machines that will run the app if it's not already installed. Just having .NET 4.0 on the machine will not work.
Also, if your application is running on a 64-bit machine, your code will run 64-bit. This is a problem if the components you're using a 32-bit. You'll have to recompile your app to target x86 only. That will force your app to run 32-bit only and thereby work with 32-bit components.
|
|
|
|
|
Thanks for the reply Dave. Should I uninstall .net4 and install 3.5? I can compile my app for 2.0 if that will help. I thought 4.0 included all subsequent versions.
|
|
|
|
|
jn6147 wrote: I thought 4.0 included all subsequent versions.
It does, but the story is a bit more complicated than that[^].
Bastard Programmer from Hell
|
|
|
|
|
No, don't uninstall it. The .NET Frameworks are designed to be installed side-by-side.
They are also NOT inclusive of previous versions.
|
|
|
|
|
Thank you for the replies. I downloaded the x64 version of the 2.0 framework, when I try to install it I get a message saying that it is already part of the OS. I also recompiled my app to target the 2.0 framework, for 64bit, any CPU. There are 4 .net services installed on the machine, the one for v2.0 will not stay running if I start it manually. Is there any way I can log what is happening? I have the Windows SDK installed on the machine with Windbg - not sure how to use it though.
Thanks
John
|
|
|
|
|
.NET is not a service. There may be service components, but they are start on demand. You do not start them yourself and they do not stay running all the time.
Your app may be running 64-bit, but the components you're using in your application, like 3rd party COM components may not be 64-bit. If that's the case, you'll have to recompile your app to force a target of "x86 Only". THis will keep your app as a 32-bit app so you can use those components.
|
|
|
|
|
Thanks Dave - I re-compiled as x86, any CPU, Debug, ran the app and it still is not working. I do however get a different, more descriptive error in the Win Eventlog:
Faulting application name: EasToTv.exe, version: 1.1.0.0, time stamp: 0x4fe9de9f
Faulting module name: vrfcore.dll, version: 4.1.1078.0, time stamp: 0x4b702994
Exception code: 0x80000003
Fault offset: 0x00003c38
Faulting process id: 0x1760
Faulting application start time: 0x01cd53b679ed9c44
Faulting application path: C:\EasWin\EasToTv.exe
Faulting module path: C:\Windows\SYSTEM32\vrfcore.dll
Report Id: dbd4ac4a-bfa9-11e1-8220-386077bf39d3
Now the app stays running in task manager, but no window is visible.
Any ideas?
John
modified 26-Jun-12 12:43pm.
|
|
|
|
|
vrfcore is the API library for MS Application Verifier. You should never see this in a .NET app (managed code) since it doesn't work with .NET at all.
Reasons why you might see a problem in here is your .NET app is interacting with the unmanaged world, either directly (Windows API functions) or in unmanaged code (like P/Invoking a function in a .DLL library) and not doing it correctly
I really have no idea what your code is doing, but it's doing something in the unmanaged world and doing it wrong. That's about as much as I can determine given the limited error information.
|
|
|
|
|
That's what scares me Dave is that I'm just calling COM functions that were written by someone else. What confuses me though is that this app runs on another Win-7 box, which leads me to believe that there may be something in the Win-7 configuration that I can tweak to get it going.
|
|
|
|
|
You're going to have to ask the people that wrote that component.
jn6147 wrote: which leads me to believe that there may be something in the Win-7 configuration
that I can tweak to get it going.
Chances are really good that's not the case. Though, your COM component may be dependent on some other libraries, of which you may have the wrong version, or it may require an updated version, such as the Visaul C++ Runtime (fill in version here).
|
|
|
|
|
|
This is not the right forum where you share some link for discussion. This is a forum where people ask technical questions related to .NET Framework, if they get stuck.
I would suggest you to post in GIT[^] or Lounge[^] to move ahead. Since you are new here, I would suggest you to post in GIT and get a little conditioned for CP.
|
|
|
|
|
ok.. Thank you.. 
|
|
|
|
|
Really? An 8 year old article??
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
